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he enhancements to Smalltalk application development provided by 
VisualWorks extend well beyond the advantages of GUI window 
painting. fundamental among these enhancements is a new applica¬ 
tion architecture that includes a type of model dedicated exclusively 
to managing an entire application—or at least an entire window. 
This type of model is implemented by the class ApplicationModel. Although Appli- 
cationModel offers a rich set of features for application management, we have 
found additional abstract subclasses of ApplicationModel, which add still more 
features, to be of tremendous benefit in our VisualWorks development. Cur¬ 
rently, we have two very mature abstract subclasses of ApplicationModel. When 
starting a new project for a client, we typically create yet another abstract subclass, 
specific to that client’s needs. These additional abstract subclasses of Application- 
Model provide several benefits: 

■ easier control of the interface 

■ additional functional features 


• lean implementations of concrete application model classes 

■ elegant and readable source code for concrete application model classes 

■ consistency of features and behavior over all concrete application model 
classes which comprise an entire application 

■ improved dialog development 


In this article, we will offer some of the more useful enhancements that have been 
developed so far: component services, aspect services, and containing model ref¬ 
erence. These features are provided in a subclass of ApplicationModel we call Ex- 
tendedApplicationModel. Although most of these ideas are quite simple, they 
greatly facilitate application model development. Also, it is important that none 
of this additional functionality interfere with, or override, what is already pro¬ 
vided in ApplicationModel. That is, any existing subclass of ApplicationModel 
should also be able to run as a subclass of ExtendedApplicationModel without any 
adjustments in its implementation, finally, we will show how to add ExtendedAp¬ 
plicationModel to your VisualWorks class creation dialog so that it is available 
when installing a canvas. 


COMPONENT SERVICES 

Component services are used to control the components—and related interface 
objects such as windows and keyboard hooks—during runtime. What they offer 
the developer is 

■ elegance of code 

■ readability ol code 
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W e’re very excited to have the opportunity to be the first to tell you about the upcoming 

changes planned for The Smalltalk Report as we start our fourth year of publication in 
September. With Smalltalk’s move into the mainstream as an application development 
tool and as the underlying scripting language for visual programming environments such 
as IBM’s VisualAge and Digitalk’s PARTS, the interest and activity within the Smalltalk 
arena is growing exponentially. Reflecting this and our rapidly growing readership, The 
Smalltalk Report will be expanded from its current 24 pages to 32 pages and will take 
on a new look with enhanced use of color throughout the publication. We will be able to 
expand the editorial content of The Smalltalk Report, which, for our readers, trans¬ 
lates into more features, articles, columns, and reviews. Over the next few months we will 
be introducing you to new columnists and new departments. 

A new feature we would like to add to The Smalltalk Report starting in September 
is something that, for the want of a better name we are calling the “Wow, that’s neat...” 
column. The idea is to have our readers contribute some small snippets of code that pro¬ 
vide some interesting or useful functionality. We are hoping that the description and code 
. together will fit into roughly one printed page. If you have some “neat things” that you 
have built in the past that you’d be willing to share with our readership, why not pass 
them on? 

We are delighted to introduce Tim Howard and Bill Kohl as new columnists this 
month. They will be writing columns that will be dealing with issues of software construc¬ 
tion using Smalltalk- Their first contribution is featured this month and deals with mak¬ 
ing extensions to VisualWorks’ Application Model by introducing useful abstract classes 
to ApplicationModel. We’re sure you'll agree that their contribution will meet the same 
high standards set by all our columnists. 

Also in this issue, two of our regular columnists return. Kent Beck is continuing with 
his “Where do objects come from?” series, which has been dealing with issues of when 
and why objects should be introduced during development. Alan Knight presents us with 
a potpourri of issues that have been raised on Internet’s comp.lang.smalltalk, which is a 
constantly growing forum in which Smalltalkers can participate. If you haven’t checked 
out comp.lang.smalltalk, you may wish to do so. Although not all of what is said there will 
be of interest to you, you will undoubtedly find gems of information to help in your work. 

Wayne Beaton returns this month with a description of extensions that can be made to 
Small talk/V’s menu facilities giving them a more object-oriented flavor. Finally, Scot Camp¬ 
bell provides a detailed inside look at Team/V, Digitalk’s facility for team development. 
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WindowBudlder 


j*o! 


The New Power in Smalltalk/VInterface Development 



Smalltalk/V developers have 
WindowBuilder as an 
essential tool for develop¬ 
ing sophisticated user inter¬ 
faces. Tedious hand coding 
of interfaces is replaced by 
interactive visual composi¬ 
tion. Since its initial release, 
WindowBuilder has 
become the industry stan¬ 
dard GUI development tool 
for the Smalltalk/V environ¬ 
ment. Now Objectshare 
brings you a whole new 
level of capability with 
WindowBuilder Pro! New 
functionality and power 
abound in this next genera¬ 
tion of WindowBuilder. 


come to rely on WindowBuilder Pro/V 


is available on Windows for $295 
and OS/2 for $495. Our stan¬ 
dard WindowBuilder/V is 
still available on Windows 
for $149.95 and OS/2 for 
$295. We offer full value 
trade-in for our 
WindowBuilder customers 
wanting to move up to Pro. 
These products are also 
available in 
ENVY’/ Developer and 
Team/V™ compatible for¬ 
mats. As with all of our 
products, WindowBuilder 
Pro comes with a 30 day 
money back guarantee, full 
source code and no Run¬ 
Time fees. 


Some of the exciting new features .,. 


• CompositePanes: Create custom controls as composites 

of other controls, treated as 
a single object, allowing the 
developer higher leverage 
of reusable widgets. 
CompositePanes can be 
used repeatedly and 
because they are Class based, they can be easily sub¬ 
classed; changes in a CompositePane are reflected any¬ 
where they are used. 



• Morphing: Allows the developer to quickly change 
Tsmniiiaik gj from one type of control 
Wndawsuiidci ■ tQ another, allowing for 

H powerful “what-if" style 

_H visual development. The 

flexibility allowed by 

morphing will gready enhance productivity. 


-Skills- 

O Smalhnlk 
O WindowBuilder 
O Other 


• ScrapBook: Another new feature to leverage visual 
component reuse, ScrapBooks provide a mechanism for 

developers to quickly 
store and retrieve pre¬ 
defined sets of compo¬ 
nents. The ScrapBook 
is a catalog of one's 
favorite interface com¬ 
ponents, organized 

into chapters and pages. 

• Rapid Prototyping capa¬ 
bilities: With the new link¬ 
ing capabilities, a develop¬ 
er can rapidly prototype a 
functional interface without 
writing a single line of 
code, LinkButtons and 
LinkMenus provide a pow¬ 





erful mechanism for linking 
windows together and speci¬ 
fying flow of control. 
ActionButtons and 
ActionMenues provide a 
mechanism for developers to 
attach, create, and reuse 


actions without having to write code. These features 
greatly enhance productivity during prototyping. 


• ToolBar: Developers can Create sophisticated toolbars 



just like the ones in the WindowBuilder Pro tool itself. 


■ Other new features include: enhanced duplication and 
cut/paste functions, size and position indicators, 
enhanced framing specification, Parent-Child window 
relationship specification, enhanced EntryField with char¬ 
acter and field level validation, and much more... 


• Add-in Manager: Allows developers to easily integrate 
extensions into WindowBuilder Pro's open architecture. 


Catch the excitement, go Pro! 

Call Objectshare for more information. 

(408) 727-3742 


Objectshare Systems, Inc 5 Town & Country Village 

Fax: (408)727-6324 Suite 735 

CompuServe 76436,1063 San Jose, CA 95128-2026 


WindowBuilder and WindowBuilder Pro are trademarks ol Objeclstiare Systems, Inc. All older brand and product names are registered trademarks ol Iheir respective companies 



























continued from page 1 


■ Extending the application model 


■ brevity of code 

• development efficiency 

■ flexibility 

• safe component access 

■ additional functionality 

After you have written a few meaningful applications in Visu- 
alWorks, you may begin to notice a certain repetition of code 
where component control is concerned. For example, suppose 
we want a method that is responsible for disabling three com¬ 
ponents—#name, #addiess, and #phone. The implementation 
for such a method might look like this: 

(self builder componentAt: #name) disable. 

(self builder componentAt: #address) disable. 

(self builder componentAt: #phone) disable. 

At first glance, one notices that this code is not very readable. A 
statement such as self builder componentAt.. .disable does not 
fit very well with our common vernacular. To a second party 
reviewing this code, it is not readily apparent what is going on. 
Smalltalk code should be short, elegant, and readable. Also, 


notice how much redundancy is involved. There is no excuse 
for this in Smalltalk, which leads us to the next implementa¬ 
tion. Most veteran Smalltalkers would implement our example 
method as follows. 

#(name address phone) do: [:each | 

(self builder componentAt: each) disable] 

An improvement, but we are still not quite there. This second 
implementation is more elegant in that it removes the redun¬ 
dancy, but it is even less readable than the first. In English, 
what we are trying to do is disable #name, #address, and 
ttphone. Is there any reason why we cannot write the method 
just this way? Certainly not! Application models that are sub¬ 
classes of ExtendedApplicationModel implement our example 
method as follows. 

self disable: #(name address phone) 

This third implementation is short, concise, and readable. In 
the time it takes to read this very short line, we know exactly 
what is taking place. Application models that are subclasses of 
ExtendedApplicationModel are able to control their compo¬ 
nents in just such a fashion. 

As another illustration of the utility 
of component services, consider chang¬ 
ing one of the colors of a component. 
This is not at all a straightforward task. 
There are some subtleties involved with 
this process and several lines of code are 
required to do the job. For example, if 
we wanted to change the foreground 
color of a component whose ID is 
#notes, then we would write something 
like the following. 

| Ip comp | 

comp := self builder componentAt: #notes. 

Ip := comp lookPreferences. 

Ip := Ip foreqroundColor: ColorValue red. 
comp lookPreferences: Ip 

This is quite a bit of code and not at all 
readable. Of course, the acid test of read¬ 
ability is to state in English exactly what 
we are trying to accomplish. In this case, 
the English version reads change the fore¬ 
ground color of #notes to the color red. 

The ExtendedApplicationModel offers a 
component service that allows us to 
write the code in just such a way. 

self change: #foregroundColor 
of: #notes to: ColorValue red 


Table 1. Component Services. 


Message 

Behavior 

abortFocusShift 
change: aSynibol of: 
aSymhalOrArray 
to: aSymbolOrColor 

Prevents a shift of focus from taking place. 

Change the color role aSymbol of the component(s) 

identified by aSymbolOrArray to the color indicated by aSymbolOrColor 

component: aSymbol 

Return the component (SpecWrapper) whose id is aSymbol 

controllerFor: aSymbol 

Return the controller for the widget identified by aSymbol 

disable: aSymbolOrArray 

Disable the component(s) identified by aSymbolOrAnay 

enable: aSymbolOrArray 

Enable the component(s) identified by aSymbolOrArray 

invalidate: aSymbolOrArray 

Redraw the component(s) identified by aSymbolOrArray 

keyboardHook 

Return the keyboard hook. 

keyboardHook: aSymbol 

Retrun the keyboard hook for the widget of the component whose ID is 
aSymbol. 

keyboardProcessor 

Return the keyboard processor. 

makelnvisible: 

aSymbolOrArray 

Make invisible the component(s) identified by aSymbolOrArray 

makeVisible: 

aSymbolOrArray 

Make visible again the component(s) identified by aSymbolOrArray 

replaceWidgetControllerln: 
aSymbol with: a 

Controller 

Replace the controller in the widget identified by aSymbol with aControtler 

takeFocus: aSymbol 

Give focus to the component identified by aSymbol 

tumOff: aSymbolOrArray 

Turn off the component(s) identified by aSymbolOrAnay 

tumOn: aSymbolOrArray 

Turn on the component(s) identified by aSymbolOrAnay 

widget: aSymbol 

Return the widget identified by aSymbol 

window 

Return the builder's window. 


Notice that we also gain in brevity and 
elegance. For someone reviewing the 
code, it is immediately obvious what this 
statement does. To provide some flexi¬ 
bility, the color argument can be either 
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Now! Automatic Documentation 


For Smalltalk/V Development Teams — With Synopsis 


Synopsis produces high quality class documentation 
automatically. With the combination of Synopsis and 
Smalltalk/V, you can eliminate the lag between the 
production of code and the availability of documentation. 

Synopsis for Smalltalk/V 

• Documents Classes Automatically 

* Provides Class Summaries and Source Code Listings 

♦ Builds Class or Subsystem Encyclopedias 

♦ Publishes Documentation on Word Processors 

* Packages Encyclopedia Files for Distribution 

• Supports Personalized Documentation and 
Coding Conventions 

Dan Shafer, Graphic User Interfaces, Inc.: 

“Every serious Smalltalk developer should take a 
close look at using Synopsis to make documentation 
more accessible and usable.” 


Development Time Savings 


Without 

Synopsis 

Coding 

Documentation 


• ; i ; ► * 

A 

A 


Start 

Finish 


Documentation 

With 

Synopsis 




A 

A 


Start 

Finish 


Products Supported: 

Digitalk Smalltalk/V Windows $295 
Digitalk Smalltalk/V OS2 $395 

(OS/2 version works with Team/V and Parts) 

Bu Synopsis Software 

8609 Wellsley Way, Raleigh NC 27613 
Phone 919-847-2221 Fax 919-847-0650 


some kind of Paint object or a Symbol identifying one of the 
named ColorValues such as #navy or #lightGray. 

As another form of flexibility, many component services 
that take a component ID as an argument can also take an Ar¬ 
ray of component IDs. For instance, we can make a single 
component invisible with 

self makelnvisible: #name 

Or with the same message, we can make an arbitrary number 
of components invisible, such as 

self makelnvisible: #(name rank serialNumber) 

The component services are also robust enough to ignore any 
errant component IDs—those that do not identify a compo¬ 
nent. The component lookup is conducted such that compo¬ 
nent IDs not found in the builder’s named components collec¬ 
tion are ignored. 

There are two component services that add some additional 
functionality not currently available in VisualWorks. These 
component services turn components off and on. Turning off a 
component is similar to disabling it in that the turned off com¬ 
ponent will not respond to user input. Unlike disabling, how¬ 
ever, the component is not redrawn in a gray hue but main¬ 
tains its original color. The implementation is quite a bit 
different as well. A component is turned off by giving its wid¬ 
get a NoController. The purpose of turning off a component is 
to provide a read only effect. Turning on a component merely 


reinstates the widget’s default type of controller so that it can 
accept user input again. 

There are 18 component services; these are listed in Table 1. 

ASPECT SERVICES 

When designing an application model that manages several 
components, the instance variable list tends to become some¬ 
what overloaded. Traditionally, good Smalltalk style frowns on 
class definitions with excessive instance variables. Such a 
symptom can be indicative of 

■ a lack of factoring in the hierarchy 

■ a lack of support object types and collaborator object types 

■ unnecessary and unused instance variables 


Table 2. Aspect service argument for ValueHolder. 


aSelector 

A Symbol which is the name of the method using 
the service. 

anObject 

The initial value of the ValueHolder. 

aSelectorOrAnay 

A Symbol or an Array. 

If it is a Symbol, it is the name of a unary message 
to be sent to the application model on a change of 
value Of the ValueHolder. 
if it is an Array, the first element Is the change 
message, and the second element is the receiver 
of the message. 
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■ Extending the application model 


In general, an excess of instance variables usually indicates that 
the class is assuming too much responsibility and that some of 
this responsibility should be defined in one or more super 
classes or delegated to collaborator and support objects. In the 
case of concrete application model development, however, 
these two options usually do not apply. This leaves only one 
avenue for reducing our number of instance variables—re¬ 
moving those that are unnecessary. Well, the aspect instance 
variables are unnecessary! The reason for this is that a 
UIBuilder caches these objects in its bindings variable. This 
means the application model maintains redundant references 
to its aspect models. The application model can always refer¬ 
ence its aspect models via its builder, so why keep them as in¬ 
stance variables? ExtendedApplicationModel uses this informa¬ 
tion to provide aspects for the components without having to 
load up on aspect instance variables. 

Typically, an aspect method returns some type of value 
model, or some other type of aspect object such as a Selec- 
tionlnList. In an extended application model, aspect methods 
can be written in one of two ways. For example, a method for 
the #documentName aspect might look like the following: 


documentName 

"self valueHolderFor: #documentName initialValue: String new 
This second implementation does not require an instance vari¬ 
able! As long as the aspect is accessed using the accessing mes¬ 
sage (a practice we strongly encourage), the correct value will 
be returned and the application model will behave just as if the 
implementation was that of the first type. Also notice how 
much more readable it is than the traditional implementation. 
There are two aspect services for ValueHolders: 

valueHolderFor: aSelector initialValue: anObject 
and 

valueHolderFor: aSelector initialValue: anObject 
changeMessage: aSelectorOrAnay 

The arguments are described in Table 2. 

There are two forms of the aspect service for SelectionlnList 
and MultiSelectionlnList 

selectionlnListFor: aSelector list: anObject 

and 


documentName 

''documentName isNil 

ifTrue: [documentName := String new asValue] 
ifFalse: [document] 


This first implementation, which is the traditional approach, 
requires the allocation of an instance variable, documentName. 
In an extended application model, the method can also be 
written as 


Table 3. Aspects service arguments for SelectianlnList. 


aSelector 

anObject 

aSelectorOrArrayl 

aSelector0rAiray2 


A Symbol that is the name of the aspect and of 
the method. 

This can be nil, a sequenceable collection, or a Symbol 
If it is nil, then an empty SelectionlnList is created. 

If it is a collection, the SelectionlnList is initialized 
with the collection. 

If it is a Symbol, then it is interpreted as a message 
sent to the application model to retrieve the list 
which is then used to initialize the SelectionlnList. 

A Symbol or Array. If a Symbol, then it is the change 
message sent to the application model on a change 
of the list. 

If an Array, then the first element is the change message 
and the second element is the receiver of the message. 
A Symbol or Array. If a Symbol, then it is the mes¬ 
sage sent to the application model on a change of 
the selection index. 

If an Array, then the first element is the change 
message and the second element is the receiver of 
the message. 


Table 4. Aspect service arguments for SubCanvas. 

aSelector A Symbol which is the name of the aspect and of the method. 
aModel A subclass of ApplicationModel or an instance of such a class. 


selectionlnListFor: aSelector list: anObject listChange: 
aSelectorOrArrayl selectionChange: aSelectorOrArrayZ 

The arguments are defined in Table 3. 

When the component is a subcanvas, then the aspect is an¬ 
other application model. The aspect service in this case is 

applicationFor: aSelector model: aModel 

The arguments are presented in Table 4. 

Also, if the sub environment is itself an extended applica¬ 
tion model, then it will automatically receive a reference to its 
containing model. The containing model properties of Ex¬ 
tendedApplicationModel are covered shortly. 

All the aspect services use the same approach. For illustra¬ 
tion, we will use the valueHolderFor:initialValue:changeMessage: 
aspect service. Whenever someone sends a message to access an 
aspect, that method’s implementation is an aspect service mes¬ 
sage. For instance, an application model with a #productID as¬ 
pect might have a method which looks like the following. 

productID 

"self 

valueHolderFor: #productID 
initialValue: String new 
changeMessage: #changedProductID 


The implementation of the valueHolderFor:initialValue:changeMes- 
sage: aspect service method defined in ExtendedApplication¬ 
Model is shown below. 

valueHolderFor: aSelector initialValue: anObject changeMessage: 
aSelectorOrAnay 

"(self builder bindings includesKey: aSelector) 
ifFalse: [self 

registerlnterestln: (ValueHolder with: anObject) 
using: aSelectorOrAnay] 
ifTrue: [self builder aspectAt: aSelector] 
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This method checks first to see if the builder already has the 
aspect model in its bindings. If so, then access it from the 
builder and return it (the ifTrue: clause). If not, then create 
the ValueHolder with the initial value of anObject and use 
the information in aSelectorOrArray to register interest in 
the ValueHolder. Then return this new ValueHolder (the if- 
False: clause). The interest in the ValueHolder is registered 
by sending the message registerlnterestln: aValueHolder us¬ 
ing: aSelectorOrArray. The implementation for this method 
is shown below. 

registerlnterestln: aValueModel using: aSelectorOrAnay 

aSelectorOrArray isNil ifTrue: [ A aValueModel]. 

(aSelectorOrAnay isKindOf: Array) 
ifTrue: [aValueModel 

onChangeSend: (aSelectorOrAnay at: 1) 
to: (aSelectorOrAnay at: 2)] 
ifFalse: [aValueModel 
onChangeSend: 
aSelectorOrAnay to: self]. 

"aValueModel 

If aSelectorOrArray is a Symbol, then it is understood that the 
interested object is the application model itself. If aSelectorOr- 
Array is an Atray, then its first element is expected to be a Sym¬ 
bol naming the change message and its second element is ex¬ 
pected to be the interested object, that is, the receiver of the 
change message. 

One caveat to using the aspect services is that the aspects are 
necessarily public. If a completely private aspect is desired, you 
must abandon the aspect services and declare an instance vari¬ 
able that does not have an accessing method. 

Although there is no functional benefit in using aspect ser¬ 
vices, we do get a threefold increase in elegance, namely, 

• a reduction in the amount of instance variables in the class 
definition 

• much more readable and descriptive aspect methods 

■ the discipline of referencing aspects by their accessing 
messages 

For example, 

Label ExtendedApplicationModel 

Aspect #superPick 

Select #ExtendedApplicationModel 

CONTAINING MODEL 

Quite often, when an application model is launched from an¬ 
other application model, the new application model will want 
to reference its parent. Also, it is quite convenient for an ap¬ 
plication model running a subcanvas to reference the con¬ 
taining application model. For these reasons, ExtendedAppli¬ 
cationModel defines an instance variable, containing Model, 
which allows an application model to reference the contain¬ 
ing application model which launching it or contains it as a 
sub environment. 


ADDING TO VISUALWORKS 

The complete source code for ExtendedApplicationModel, 
along with an example application, can be acquired from the 
University of Illinois Smalltalk Archives in ST_80VW directory 
as “extendedApplicationModel.st.” To make ExtendedApplica¬ 
tionModel available from the class creation dialog, open the in¬ 
terface in UIFinder class»classCreationDialog for editing. Now 
add a radio button below the ApplicationModel radio button. 
Give this new radio button the following properties and install 
the canvas. 

To make ExtendedApplicationModel the default selection for 
this dialog, you must edit the UIFinder class method 

openNewClassDialogForName: aClassName subclassing: aSuperName 
inCategory: aCategory 

This is a very long method. Find the part that reads 
builder 

aspectAt: #superPick 
put: 

(superPick := 

(superName value isEmpty 
ifTrue: [#ApplicationModel] 
ifFalse: [#0ther]) asValue). 

and change the ifTrue: value form #ApplicationModel to #Ex- 
tendedApplicationModel. This will make ExtendedApplication¬ 
Model the default superclass of any new classes created as a re¬ 
sult of installing a canvas. 

CONCLUSION 

VisualWorks projects of any merit should include one or more 
abstract subclasses of ApplicationModel to facilitate application 
development. In this article, we developed such a class, Ex¬ 
tendedApplicationModel, and populated it with some very useful 
features: component services, aspect services, and a containing 
model reference. Component services facilitate the control of 
the interface objects during runtime and provide more readable 
and elegant implementations. The aspect services eliminate the 
need to load up on instance variables when defining an applica¬ 
tion model class and also provide brief, readable aspect method 
implementations. The containing model reference is an instance 
variable that allows an application model to reference its parent 
or containing model for which it serves as a subenvironment. 
These three enhancements are good examples of why it is advan¬ 
tageous to create abstract subclasses of ApplicationModeL HO 

Tim Howard holds an MBA and a MS in Industrial Engineering 
and has been developing application software for eight years. 
Presently he is working on a VisualWorks book for SIGS Publica¬ 
tions and consults for RothWell International. He can be reached 
at the RothWell offices at 800.256.0541, at home at 713.784.9730, 
or via email at 74213.1517@compuserve.com. 

Bill Kohl is a Training Administrator at RothWell International 
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“Smart Menus” 


in Smalltalk/V 


for Win32 


Wayne Beaton 

enus play an important role in any Windows- 
based application. Typically, an application will 
“gray-out”, or disable menu entries that don’t 
make sense in the current context. Menu items 
may or may not have a check mark to their left, 
indicating that an option is active or inactive. Managing these 
menu items can be cumbersome, if not downright difficult us¬ 
ing the mechanisms built into Smalltalk/V (for large applica¬ 
tions, it certainly takes far too much effort to get menus to op¬ 
erate correctly). 

The current mechanism feels a lot like functional program¬ 
ming: if, for example, an application has a menu titled ‘File 1 
and a menu titled ‘Edit’, each containing a number of entries, a 
ViewManager subclass might have code to update these menus 
which looks something like: 

self isDocumentDirty 
jfTrue: [ 

(self menuTitled: 'File') 
enableltem: #fileSave] 
ifFalse: [ 

(self menuTitled: 'File') 
disableltem: #fileSave]. 

self clipboardContainsObject 
ifTrue: [ 

(self menuTitled: 'Edit') 
enableltem: #editPaste; 
enableltem: #editPasteSpedal] 
ifFalse: [ 

(self menuTitled: 'Edit') 
disableltem: #editPaste; 
disableltem: #editPasteSpecial] 

(. . .etc. . .) 

For a small number of entries, this technique may be easy to 
understand and use. As the size of the application and the 
number of menus increase, this type of code can grow exceed¬ 
ingly complex. To start, the label of the menu is required to ac¬ 
cess it. If the application is required to function in multiple 
languages, this issue becomes even more complex (the typical 
solution might be to have a specific method that will determine 
each menu title). If the logic that determines the enabled or 
disabled state gets any more complicated, the method becomes 


so nested that even expert Smalltalkers choke, gag and eventu¬ 
ally collapse and die. 

AN OBJECT-ORIENTED APPROACH? 

As strange as it may seem, Smalltalk is object-oriented, which 
means (in part) that objects know things about themselves. 
Why not have menus know how to update themselves? 

When a menu item is created, a label, selector and accelera¬ 
tor is specified for it. The label is the string that will be dis¬ 
played for the user when the menu is selected and pulled 
down. The selector is a unary message that will be sent to the 
menu’s owner when the item is selected by the user and the ac¬ 
celerator is a description of the keyboard equivalent of select¬ 
ing the item. 

Smart menus will consider additional information. When 
an item is added to a smart menu, the programmer can also 
specify a block of code as the “enabled condition” for the 
item. The block must result in a Boolean when evaluated—if 
the result is true, the item will be enabled, if false the item 
will be disabled. Similarly, the programmer can specify a 
“checked condition” which is also a block resulting in a 
boolean which determines if the item is checked or not. If no 
conditions are specified, then by default an item will be en¬ 
abled and unchecked. 

A subcass of Menu has been introduced named SmaitMenu 
(see listings 1 and la) that handles menu updating. A single 
method has been added to MenuWindow (see listing 2) to sim¬ 
plify the interaction between an application and its menus. 

A menu is created using the existing methods in class menu. 
Enabling and checking behavior can be added for an item after 
that item has been added. For example, to create a “File” 
menu, a method using the following code might be employed: 

buildFileMenu 

"Build and answer the menu titled 'File'." 

A SmartMenu new 
owner: self; 
title: 'File'; 

appendltem: 'Open...' selector: #fileOpen; 
appendltem: 'Save' selector: #fileSave; 
enableltem: #fileSave 
when: [self isDocumentDirty]; 
yourself 

This method builds a menu titled “File” with two entries. The 
entry labeled “Open...” is always enabled. The entry labeled 
"Save” is only enabled when the document is dirty. 

There are two ways that the menu updating process can be 
initiated. Before a menu is pulled down, the menu window is 
triggered with the event aboutToDisplayMenu; the handler for 
this event can send the message updateMenus to the 
menuWindow. Alternately, the menuWindow can be asked at 
any time to update its menus (again using the message up¬ 
dateMenus). 

The class ClassList has been created to demonstrate the use 
of SmartMenus (see listing 3). This class builds a window con¬ 
taining a list box populated with the classes known to the sys- 



May 1994 


9 


■ “Smart Menus” in Smalltalk/V for Win32 


This method remembers the selected class and updates the 
menus by sending the message updateMenus to the MenuWindow. 

SOME CONCLUSIONS 

Smalltalk/V provides a rich set of user interface tools, but it 
seems they have not yet evolved aspects of it into a more usable 
form. As is often the case, the environment can be manipu¬ 
lated into a more usable form with minimal impact. 

The code presented here is only a first step. With some 
imagination, there are other facilities that can be integrated 
easily. Enabling and disabling items is something that most, if 
not all, applications do. Some applications dynamically change 
the contents of some menus, change the text of some entries, 
or even include a graphic that may change. Such less-generic 
behaviour can be easily added. 11 

Wayne Beaton is a senior member of the Development Team at 
the Object People. His interests include User Interfaces, Neural 
Networks, and snickering of people who wear socks with sandals. 
He can be reached at The Object People in Ottawa at 
613.225.8812 (Wayne@ObjectPeople.on.ca). 


1 Listing 1. The class SmartMenu. | 

itemCheckConditions 


"Private - Answer my collection of check conditions." 

Menu subclass: #SmaitMenu 

A itemCheckConditions! 

instanceVariableNames: 


1 itemEnableConditions itemCheckConditions 1 classVariableNames:" 

itemCheckConditions: aDictionary 

poolDictionaries:" ! 

"Private - Set my collection of check conditions." 


itemCheckConditions := aDictionary! 

ISmartMenu methods ! 



itemEnableConditions 

checkltem: aSymbol when: block 

"Private - Answer my collection of enable conditions." 

"Set a check mark beside the item only when block evaluates true." 

A itemEnableConditions! 

self itemCheckConditions 


at: aSymbol put: block. 

itemEnableConditions: aDictionary 

self updateltemWithSelector: aSymbol! 

"Private - Set my collection of enable conditions." 


itemEnableConditions := aDictionary! 

enableltem: aSymbol when: block 


"Enable the item named aSymbol only when block evaluates true." 

itemSelectorsDo: block 

self itemEnableConditions 

"Private - Evaluate block with the selector for each of my selectors 

at: aSymbol put: block. 

as parameter." 

self updateltemWithSelector: aSymbol! 

items do: [:item | 


block value: item selector]! 

initialize 


“Private - Initialize myself." super initialize. 

shouldltemBeChecked: aSymbol 

self 

"Private - Answer whether the item named aSymbol should be 

initializeltemEnableConditions; 

checked or not." 

initializeltemCheckConditions! 

A (self itemCheckConditions 


at: aSymbol ifAbsent: ["false]) value! 

initializeltemCheckConditions 


"Private - Initialize my collection of check conditions." 

shouldltemBeEnabled: aSymbol 

self itemCheckConditions: Dictionary new! 

"Private - Answer whether the item named aSymbol should be 


enabled or not." 

initializeltemEnableConditions 

"(self itemEnableConditions 

"Private - Initialize my collection of enable conditions." 

at: aSymbol ifAbsent: ["true]) value! 

self itemEnableConditions: Dictionary new! 



update 

isSmartMenu 

"Update all of my items." 

"Answer whether I am an instance of SmartMenu." 

self itemSelectorsDo: [:each | 

"true! 

self updateltemWithSelector: each]! 


tern (see Fig. 1). A single 
menu, titled “Class” is 
added containing two en¬ 
tries. The first entry, la¬ 
beled “Class Is Variable”, 
is always disabled and 
checked only if the selected 
class is a variable byte 
class. The second entry, la¬ 
beled “Browse”, is enabled 
only if a class is selected 
and is never checked. 

The menu is created in response to the event needsMenu. 
When this event is encountered, the method updateClassList- 
BoxMenu: assigns the menu created by the method buildClass- 
Menu to the list box using the SubPane method setMenu:. The 
method buildClassMenu generates a new instance of SmartMenu 
by adding each item, and then indicating under what condi¬ 
tions each item is enabled or checked. 

When a class in the list is selected, the event clicked: is trig¬ 
gered, sending the method clickedClassListBox: to the ClassList. 



ActionSequence 

CompiledMethod 

Compiledlnitializer 

ByteArray 

Interval 

String ^ ^ ^ . 

Figure 1. An instance of ClassList. 
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updateltemWithSelector: aSymbol 

enableltem: #browseClass 

"Private - Update the item with selector aSymbol. First enable or 

when: [self selectedClass notNil]; 

disable the item based on the value of the appropriate enable 
block. Second, check or uncheck the item based on the value of 
the appropriate check block." 

yourself! 

(self shouldltemBeEnabled: aSymbol) 

classlist 

iflriie; [self enableltem: aSymbol] 
ifFalse: [self disableltem: aSymbol], 

"classlist! 


classlist: aCollection 

(self shouldltemBeChecked: aSymbol) 

classlist := aCollection! 

ifTrue: [self checkltem: aSymbol] 
ifFalse: [self uncheckltem: aSymbol]!! 

clickedClassLdstBox: selectedltem 


self selectedClass: selectedltem. 

1 Listing la. E)ctenstion to class Object. 1 

self menuWindow updateMenus! 

! Object methods ! 

open 

"Open myself on all the classes in Smalltalk." 

isSmartMenu 

"Answer whether I am an instance of 

self openOn: 

(Smalltalk rootClasses 
inject: OrderedCollection new 
into: [:sum :each | 

sum 

SmartMenu." 

"false! ! 

addAll: each withAHSubclasses; 
yourself])! 

openOn: aCollection 

1 Listing 2. Extension to class MenuWindow. 1 

IMenuWindow methods ! 


"Open myself on the list of classes in aCollection." 

updateMenus 

1 pane | 

"Force my menus to update themselves." 

self 

menus do: [:each | 

classlist: aCollection; 

each isSmartMenu 

label: 'Class list'; 

ifTrue: [each update]]! ! 

addSubpane: 


((pane := ListBox new) 

I Listing 3. The class ClassLister. 1 

owner: self; 


setName: #classlistBox; 

ViewManager subclass: #ClassLister 
instanceVariableNames: 

when: #needsMenu 

send: #updateClasslistBoxMenu: 
to: self with: pane; 
when: #needsContents 
send: #updateClasslistBox: 
to: self with: pane; 

1 classlist selectedClass' 
classVariableNames:" 
poolDictionaries: " ! 

! ClassLister methods! 

when: #clicked: 

send: #clickedClassListBox: to: self; 

browseClass 

yourself). 

"Browse the selected class," 

self selectedClass edit! 

self openWindow! 

buildClassMenu 

"Private - Build and answer the class menu." 

selectedClass 

"selectedClass! 

"SmartMenu new 
owner: self; 
title: 'Class'; 

selectedClass: aClass 

selectedClass := aClass! 

appendltem: 'Class Is Variable' 
selector: #classIsVariable; 
appendSeparator; 
appendltem: 'Browse' 
selector: #browseC1ass; 

updateClassListBox: alistBox 
"Update the contents of the class list box." 
alistBox 

contents: self classlist; 
selection: self selectedClass! 

enableltem: #classIsVariable when: [false]; 
checkltem: #classIsVariable when: 

[self selectedClass notNil 
and: [self selectedClass isVariable]]; 

updateClasslistBoxMenu: alistBox 

“Update the menu for my class list box." 
alistBox setMenu: self buildClassMenu! ! 
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Gearing tee new client and server applications 
would be far more rewarding if you could reuse 
existing code instead of rewriting it. And now 
that goal becomes reality with object-oriented 
programming. Especially when you can rely 
on VisualWorks" the ParcPIace Smalltalk" 
Applications Development Environment that 
creates applications that are instantly portable 
between Windows, OS/2, Macintosh ond UNIX. 
True OOP, it provides a robust set of tools to 
build sophisticated graphical applications with 
occess to a wide variety of relational databases. 
Fully armed with superior flexibility, dynamic 
compilation for impressive performance and the 
world's largest set of tried and tested class 






have selected VisualWofks for client ond server 
development. And stopped rewriting history. 



VisualWorks 


DEVELOPERS WHO DO NOT 


REMEMBER HISTORY ARE 


ParcPIace® 
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HE BEST OF comp.lang.smalltalk 


Alan Knight 


Miscellaneous 


T his month’s column covers several unrelated things 
that don’t require an entire column’s worth of space. 
This includes some recommended reading, the an¬ 
nouncement of a new version of the Self language, a template 
of examples for class comment rules used in the APOK tool kit, 
and a handy bit of code for finding references to objects in 
ParcPlace Smalltalk. 

READING MATERIAL 

Books on Smalltalk programming are coming out regularly, 
but the most interesting Smalltalk-related reading I’ve come 
across lately has little to do with programming. It’s Alan Kay’s 
“The Early History of Smalltalk,” part of the Second History of 
Programming Languages conference (HOPL-II) sponsored by 
the Association for Computing Machinery (ACM) Special In¬ 
terest Group on Programming Languages (SIGPLAN). 

The conference covers the early history of more than 14 
different programming languages, including Smalltalk and C++ 
(SIMULA was covered in the first HOOPLA). I naturally 
thought the Smalltalk article was the highlight, but I found the 
whole thing very interesting. I include a few choice quotes 
from the article: 

One way to think about progress in software is that a lot of 
it has been about finding ways to late-bind, then waging 
campaigns to convince manufacturers to build the ideas 
into hardware. 

A language I now called “Smalltalk”—as in “program¬ 
ming should he a matter of..and “children should pro¬ 
gram in.... ” The name was also a reaction against the 
“Indo European god theory,” where systems were named 
Zeus, Odin and Thor, and hardly did anything. I figured 
that “Smalltalk” was so innocuous a label that if it ever did 
anything nice people would be pleasantly surprised. 

... I think the enormous commercialization of personal 
computing has smothered much of the kind of work that 
used to go on in universities and research labs, by sucking 
the talented kids towards practical applications. 

Should we even try to teach programming? I have met 
hundreds of programmers in the last 30 years and can see 
no discernible influence of programming on their general 
ability to think well or take an enlightened stance on hu¬ 
man knowledge. If anything, the opposite is true. 


I received the preprints of the conference papers as a special is¬ 
sue of SIGPLAN notices. I understand, however, that a book 
including these papers and much other conference material is 
being planned. Unfortunately, it won’t be published until 
sometime in 1995. In the meantime, the preprints are available 
from the ACM: US $27 for ACM members and US $54 for 
nonmembers. The order number is 548931, ISBN 0-89791- 
5704. The ACM publications office can be reached at 
800.342.6626 or 212.626.0500 or at P.O. Box 12114, Church 
Street Station, New York, NY, 10257 USA. 

SELF 

Self is a prototype-based experimental language similar in 
many ways to Smalltalk, with a very aggressive optimizing 
compiler. It’s often mentioned in discussions about optimizing 
Smalltalk. If you’re interested in checking it out for yourself 
and have a Sun workstation handy. Version 3.0 was recendy 
announced. Excerpts from the announcement follow: 

The Self Group at Sun Microsystems Laboratories, Inc., 
and Stanford University is pleased to announce Release 
3.0 of the experimental object-oriented programming 
language Self.... 

Designed for expressive power and malleability, Self 
combines a pure, prototype-based object model with uni¬ 
form access to state and behavior. Unlike other languages, 
Self allows objects to inherit state and to change their pat¬ 
terns of inheritance dynamically. Self s customizing com¬ 
piler can generate very efficient code compared to other 
dynamically-typed object-oriented languages. 

The latest release is more mature than the earlier re¬ 
leases: more Self code has been written, debugging is easier, 
multiprocessing is more robust, and more has been added 
to the experimental graphical user interface which can now 
be used to develop code. There is now a mechanism (still 
under development) for saving objects in modules, and a 
source-level profiler. 

The Self system is the result of an ongoing research pro¬ 
ject and therefore is an experimental system. We believe, 
however, that the system is stable enough to be used by a 
larger community, giving people outside of the project a 
chance to explore Self. 

This release is available free of charge and can be ob- 
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tamed via anonymous ftp from Self.stanford.edu. Also avail¬ 
able for ftp area number of published papers about Self. 

There is a mail group for those interested in random 
ramblings about Self: Self-interest@Self.stanford.edu. Send 
mail to Self—request @self.stanford.edu to be added to it 
(please do not send such requests to the mailing list itself!). 

Self currently runs on SPARC-based Sun workstations 
running SunOS 4.1.x or Solaris 2.3. The Sun-3 implemen¬ 
tation is no longer provided. 


^ I have met hundreds of 
programmers in the last 30 years and 
can see no discernible influence of 
programming on their general ability 
to think well. ^ 


CLASS COMMENT RULES 

Part of ParcPlace's Advanced Programming ObjectKit (APOK) 
is a class reporter that includes checking parts of class com¬ 
ments against some simple rules. This is good. In my experi¬ 
ence, there are far too many classes out there in real products 
that have no comments at all. Of those that do, far too many 
are inadequate or out of date. Let’s face it. When you’re on a 
roll, writing detailed comments to explain everything just 
slows you down. Going back afterward and figuring out which 
comments need to be fixed is tedious and annoying. It’s too 
easy to just skip it and let things get a little bit out of sync. You 
can fix it later. Naturally, later never arrives. To help prevent 
this, comment checking should be an important part of any 
code review. A tool to make some of this checking automatic is 
a godsend for reviewer and programmer alike. 

The rules that it checks, while relatively simple, aren’t that 
well documented. It always seems easier to just refer to other 
class comments for examples (I have to congratulate ParcPlace 
for actually having class comments and for following their own 
rules). In the interests of making commenting easier, Niklas 
Bjoernerstedt (nbt@fimsys.se) has written some templates for 
these rules. They are reproduced below: 

Instance Variables: 

bufferType <nil | String class 

> Class of the byte-type object used to store data from the io 

Connection 

ClassVariables: 

IM90Roots <Set of. IM900bject> 

Class Instance Variables: 

activated <true | false | nil > Holds the activated status of the 
application 
Pool Dictionaries: 


IOConstants <Dicrionary> of characters keyed by symbols 

Subclasses must implement the following messages: 
printing 

defaultRelationType 
class protocol 

instance creation 
newApp 

FINDING REFERENCES IN PARCPLACE SMALLTALK 

Tracking down references to objects using allOwners can be 
painful. One problem is that the process of searching for refer¬ 
ences generates more references. This is particularly noticeable 
in ParcPlace Smalltalk, where it is common to see half a dozen 
“false” references among one or two real ones. Many of these 
are arrays, and it can be troublesome to pick out which are le¬ 
gitimate references and which are artifacts of the search process. 

To help filter out these false references, Jan Steinman 
(jan.bytesmiths@acm.org) provides the following bit of code. 
This should be added as a method in Inspector, and the field- 
Menu method modified to call it (don’t forget to evaluate In¬ 
spector ftushMenus) 

inspectHolders 

"Inspect all who have a reference to the fieldobject. Do not include 
references generated by the reference gathering process!" 

(self fieldValue allOwners reject: [:each | 

"don't include the object under inspection (it always contains the 
field object)" 
each = object 

"don't include this inspector (in case the field is ’self)' 1 
or: [each == self 

"don't include the methods that got us here" 
or: [(each class == MethodContext 
and: [each selector == #allOwners 
or: [each selector == #allOwnersWeakly:]]) 

"don't include the stack array with a temporary variable containing 
the object" 

or: [each class == Array 
and: [each size = 12 
and: [each first == false 

and: [(each at: 2) == self fieldValue]]]]]]) inspect 

This isn’t foolproof (in a pathological case, it could filter out a 
legitimate reference), and it doesn’t do much filtering that 
couldn’t be done manually, but I find it very useful. It clears 
away the clutter and allows you to concentrate on the impor¬ 
tant references. I added one extra line, each==self, to this 
method because often I seemed to be using it on inspectors 
with the field for self selected giving me an extra reference 
from the inspector itself. 

Note that in ParcPlace, Smalltalk references sometimes hang 
around awhile after they should be garbage, presumably due to 
WeakArray references. This can be confusing, so when in doubt, 
force a garbage collect from the Launcher and see if it helps. IB 


Alan Knight is an object person with The Object People. He can be 
reached at 613.225.8812 or by email at knight@acm.org. 
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MALLTALK IDIOMS 


Where do objects come from? 
From variables and methods 


L et’s see if I can get through this third column on how 

objects are bom without blushing. So far we’ve seen two 
patterns: objects from states and objects from collec¬ 
tions. This time we’ll look at two more sources of objects: ob¬ 
jects from variables and objects from methods. All four pat¬ 
terns have one thing in common—they create objects that 
would be difficult or impossible to invent before you have a 
running program. 

These patterns are part of the reason I am suspicious of any 
methodology that smacks of the sequence, “design, then pro¬ 
gram.” The objects that shape the way I think about my pro¬ 
grams almost always come out of the program, not out of my 
preconceptions. Thinking “the design phase is over, now I just 
have to push on and finish the implementation” is a sure way 
to miss these valuable objects and end up with a poorly struc¬ 
tured, inflexible application to boot. 

PATTERN: OBJECTS FROM VARIABLES 

Problem: How can you simplify objects that have grown too 
many variables? 

Constraints: It is common to add a variable to an object 
during development, then add related variables later, After a 
while, this process of accretion can lead to objects that have 
many variables. Such objects are difficult to debug, difficult to 
explain, and difficult to reuse. 

Still, the object more than likely works as desired. You’d 
like to avoid changing code and risking breaking the system for 
no reason. You will pay a space penalty for breaking the object 
up, as each object requires an 8 or 12 byte overhead. 

Solution: Take variables that only make sense together and 
put them in their own object. Move code that only deals with 
those variables into methods in the new object. 

Example: The classic example of this pattern is dimen¬ 
sioned numbers. Because Smalltalk doesn’t have a built-in 
framework for dimensioned numbers, programmers often 
simulate computing with dimensions by storing a value and a 
dimension together: 

Class: Page 

variables: lines widthNumber widthUnits heightNumber heightUnits 

Code has to take the different possibilities for units into account: 
area 

| widthlnches heightlnches | 


widthlnches := widthNumber * 

(widthUnits = #mm ifTrue: [25.4] iffalse: [1]). 
heightlnches := heightNumber * 

(heightNumber == #mm ifTrue: [25.4] iffalse: [1]). 

''widthlnches * heightlnches 

The number and units for width don’t make sense without one 
another. Take away one variable and the other no longer is 
useful. The same is true for height. Both are candidates for ob¬ 
jects from variables. First we have to create a Length object to 
hold both the measure and units: 

Class: Length 

variables: magnitude units 

Now the Page can be simplified: 

Class: Page 

variables: lines width height 

and the area method can be simplified, too: 
area 

’'(width * height) inches 

I’ll leave the implementation of Length arithmetic as an exer¬ 
cise for the reader and maybe as the subject of a future column. 

Once you have Length, you will find many places to use it. 
The resulting code will be much cleaner, easier to read, and 
more flexible. If you have to add cubits as a measure, you 
won’t have to visit a hundred methods, you’ll just have to fix 
Length. Following up on object from states, I suppose this is 
another way to avoid the need for case statements. Rather than 
build the cases into many different methods, you build it into 
one object and hide the caseness of it. 

How can you know when and how to simplify an object 
that seems to have too many variables? You should obviously 
avoid the extremes: no object with fewer than two variables 
will work because you’d never have enough information in one 
place to write a readable method. All the variables in the world 
in one object would result in an entirely unreadable, un- 
reusable mess. How can you walk the delicate line between 
breaking objects up too much and too little? 

One telling sign that this pattern is appropriate is when you 
have two variables in an object with the same prefix and differ¬ 
ent suffixes. Thus, if you see headCircumference and head- 
Weight as variables, they likely could be factored into their own 
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ODBMS 



ODBMS 2.0 

Smalltalk Object Management 


Client-Server Architecture 
Object Management supporting 
Versions, Transactions, Distribution 
Multimedia-Objects 
Objects to RDBMS 

Available as 

Single User, Network and Server Version 

Supports Smalltalk under 
Windows, Windows NT, OS/2, Unix 

Successful applications: 

S mal l talk Team Development 
Personal Data Manager 
Configuration of Complex Systems 


Objectoriented Technology by 

VC Software 

USA: VC Software, Houston TX 
v. (713) 333-8936, ft (713) 333-3743 

Germany: VC Software Construction 
FetritnrwaU 28,38118 Braunschweig, 
w +49 531 24240-0, ft +49 531 24244L24 

USA: Object Power, Harvard MA 
r. (508) 456-8854, ft (508) 263-0696 
UK: Cocking & Drury, London 
v. +44 71 436 9481, ft +44 71436 0524 



object, reducing the original object’s variable count by one. 

Now for the second pattern du jour, objects from methods. 
This isn’t a pattern I have. (This is a usage that has spread 
quickly in the pattern community. You’ll present a pattern and 
someone will say, “I have that pattern,” meaning they use it, 
even if they haven’t ever articulated it before.) Several people I 
respect have reported excellent results with it, so I’ll do my best 
to make the case for it. Perhaps there is something else in my 
programming style that causes me to find these objects another 
way, or maybe I just never find them. I haven’t really thought 
much about it. Anyway, here is the pattern: 

PATTERN: OBJECTS FROM METHODS 

Problem: Sometimes you write a method that is too long to 
read well. Reduction with the usual techniques (e.g., compose 
methods), doesn’t seem to make it read any better. How can 
you simplify methods that resist easy reduction? 

Constraints: Creating a new object is one of the weightiest 
conceptual decisions you can make when programming with 
objects. You should never make the decision to create one 
lighdy. If the object in question has no obvious counterpart in 
the problem domain, you should be even more careful. The in¬ 
creased load on downstream programmers is one reason to 
create as few kinds of objects as possible. The tendency of ob¬ 
jects to leak into the user’s consciousness is another. 

Objects are great for structuring information, particularly 
information that has a behavioral or computational compo¬ 
nent. They are good for representing not just the user’s view of 
a program, but the programmer’s view as well. When you have 
tried simpler methods of writing a computation and failed to 
produce a result that effectively communicates your intent as a 
programmer, you are justified in creating new objects to sim¬ 
plify your computation. 

Methods that are candidates for this treatment have several 
features in common. First, they are long. Two, three, and four 
line methods composed out of other provocatively named 
methods generally communicate well. 

Second, they are not easily shortened by splitting them into 
smaller methods. This may be because the parts of the method 
don’t make sense when separated, or it may be because you 
have to pass so many parameters to the submethods that you 
have trouble naming them all meaningfully. The submethods 
may also need to return two or more values. Finally, such 
methods often have many temporary variables (resulting in the 
many parameters to the submethods). 

Solution: Create an object encompassing some of the tem¬ 
porary variables from the complex methods that manipulate 
those variables into the new object. In the original method, 
create one of the new objects and invoke it. 

Example: As I said in the preamble, I don’t have a good ex¬ 
ample of this pattern. I have used object languages that didn’t 
have points, however, and I can imagine discovering them us¬ 
ing this pattern. If you have a method that displays a sequence 
of pictures: 

continued on page 21 
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RODUCT REVIEW 


Digitalk’s Team/V 


Scot Campbell 


S malltalk is a highly productive programming environ¬ 
ment. Starting with the mature base class library, devel¬ 
opers add new classes and new behavior to existing 
classes using the interactive browsers, inspectors, and debug¬ 
gers of the environment. However, after reaching a given mile¬ 
stone in the development process, the developer is left with the 
question, “What did I add to the base image?” 

Smalltalk teams, as all software development teams, gener¬ 
ally have the challenge of delivering high-quality products un¬ 
der tight timetables. Smalltalk teams have the added pressure 
of “proving” the new technology to management. Shipping a 
module with a missing method or an uninitialized variable can 
be detrimental to these ends, and Murphy’s Law predicts the 
certainty of a runtime error occurring from the omission. 
Team/V, from Digitalk, is team-oriented configuration man¬ 
agement software that aids in structuring the project and deliv¬ 
ering complete applications. 

The other most notable product in this category is 
ENVY/Manager, from Object Technology International, Inc., 
which has been previously reviewed in this publication. 1 This 
article explains the functionality and features of Team/V and 
highlights areas where it differs from ENVY/Manager. 

Team/V addresses the major issues of team development in 
Smalltalk: 

1. Identification of the additions to 
the image that make up the appli¬ 
cation. 

2. Coordinating the efforts of the de¬ 
velopment team. 

3. Version Control. 


TEAM/V CONCEPTS 

Team/V adds mechanisms and tools to 
help structure and manage the work of a 
team. Packages organize the code that 
help to identify the makeup of the appli¬ 
cation and coordinate the efforts of indi¬ 
vidual members. New browsers work with 
packages, and version control mechanisms 
manage changes to packages. Versions of 
packages are saved in a repository where 
they can be loaded by other team mem¬ 


bers as development progresses. Comparison browsers highlight 
the differences between any two versions of a package. 

PACKAGES 

The fundamental organizing structure in Team/V is the Pack¬ 
age. A Package is intended to encapsulate one unit of function¬ 
ality. For example, the set of classes and methods that support 
asynchronous communications could form a package. In addi¬ 
tion to being a unit of functionality, the package is also a unit 
of sharing, being used by any applications that require the 
function. By assigning the packages among the developers of a 
team, a project can distribute the work to be done. A package 
consists of the following: 

■ Name —for identification purposes (this name appears in 
the browsers), 

■ Annotations —are simply key/value pairs for commenting 
the package, 

■ Comment —a predefined annotation, 

■ Definitions —are ordered collections of units of Smalltalk code. 

Packages roughly correspond to ENVY Applications, however, 
there are differences. ENVY applications maintain two relation- 
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Figure 1. The Package Browser. 
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TlmeZones := Dictionary new 
at: 'ADT' put: -8; 
at: 'AST' put: -9; 
at: 'BST' put: 9; 
at: 'CDT‘ put: -5; 
at: 'CEST' put: t; 
at: 'CET' put:2; 
at: “CST* put: -6; 
at: 'EDT' put: -A; 
at: 'EST' put: -5; 
at: 'GMT' put: 0; 
at: 'HKT' put: 8; 


Figure 2. The Definition Organizer. 


ships. The first, prerequisites, indicate what other applications 
are required before a given application can be loaded. OTI 
claims that prerequisites are essential for supporting the con¬ 
cept of pluggable software components while Digitalk claims 
they limit reusability. Both positions are valid. Anything we add 
in Smalltalk is based upon what already exists, and in fact an 
application named “Kernel” (which includes most of the base 
class library) becomes the default prerequisite for any applica¬ 
tion we define. And documenting what services are required 
and enforcing the requirement is helpful, in fact, essential to 
prevent errors. However, the biggest challenge in effectively us¬ 
ing either of these products is coming up with the best configu¬ 
ration of packages or applications. A poor configuration of ap¬ 
plications will lead to overlapping and unnecessary prerequisite 
relationships that can limit reusability. 

The second relationship supported by ENVY applications 
are subapplications, which is a partial relationship. A subappli¬ 
cation is a part of an enclosing application. The most common 
usage of this is for multiplatform development, where the ap¬ 
plication contains function common to all platforms, and sub¬ 
applications contain platform-specific code when it is required. 
Subapplications can be nested, which allows the project to bet¬ 
ter organize the classes in a large application. 

DEFINITIONS 

Definitions are the main component of a package. 

An element in the definitions list can be one of the following: 

Class —both definition and methods, 

Class Extension —methods for a class, no definition (called 
“loose methods ” in the Team/V documentation), 

Global variable. 

Pool Dictionary, 

Initializer —an arbitrary Smalltalk expression whose primary 
purpose is initializing objects. 


A new browser, the Definition Organizer, provides the capa¬ 
bility to order the definitions. By sequencing the definitions, 
you can ensure that needed initialization is run before any 
component that requires the initialization. The Definitions 
concept appears more flexible than the collection of defined 
and extended classes in an ENVY application or subapplica¬ 
tion. The Team/V documentation talks of the elements of a 
class definition ( instance vars, class vars, class instance vars, 
and the pool usage), as discrete items in the definitions. 
While this is currently not possible, they have plans to sup¬ 
port class extensions that contain more than just a set of 
methods. You could then have an extension that added some 
methods and a needed instance variable, required only by 
the extension. 

The other area where definitions appear more flexible is in 
the ordering of the definitions. ENVY adds protocol to per¬ 
form initialization before or after an application is loaded. The 
loaded and removing methods are commonly implemented for 
applications in ENVY. The loaded method can be used for ini¬ 
tializing classes in the application. Team/V defines a class ini¬ 
tializer, which puts the initialization with the class. The ENVY 
removing method is commonly used for cleaning up the image 
when an application is unloaded, such as removing a global 
variable. In contrast, with Team/V, because the global is part of 
the definition, when a package is deleted, any unreferenced 
globals defined in the package are removed automatically. 

An example ad-hoc initializer given in the tutorial tests the 
package after it is loaded. This rigor would go a long way in test¬ 
ing prerequisite conditions, ensuring that the image the package 
is loaded into will support the requirements of the package. 

VERSION CONTROL 

The Glossary that comes with the Team/V documentation 
defines a revision as “One of potentially many incarnations of 
a given package” while it defines a version as “One of poten¬ 
tially many incarnations of a given definition.” The distinction 
is not critical; however, I will attempt to use them in their cor¬ 
rect context. 

When a package is “committed” the package is stored in a 
repository under a specified revision number. Team/V sup¬ 
ports repositories managed with Intersolv’s PVCS or the file 
system of the OS being used. The PVCS repositories are more 
space efficient, as only the delta between revisions is stored, 
and all revisions can be stored in one archive. PVCS also in¬ 
cludes access control mechanisms to limit who can make a new 
revision of a package and mechanisms to deal with concurrent 
commitment. You do not have to separately purchase PVCS to 
use the PVCS archives; Team/V ships with support that allows 
it to utilize PVCS archives. 

ENVY defines component ownership, classes have owners 
and applications have managers. Although any developer can 
modify a class, it is the owner who maintains the major path of 
development for the class. The application manager is the only 
one who can release an application, thereby making it available 
for others. 
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With the purchase of the fuil PVCS product, Team/V 
users can put controls on who can modify or release a pack¬ 
age. Without having the full PVCS product, I was unable to 
determine if PVCS provides the flexibility or dynamics pro¬ 
vided by ENVY. 

OTHER FEATURES 
Class Definition 

Class definition is done through a formatted pane on the 
package browser. In addition to naming the class, its super¬ 
class, instance variables, class variables, and pools that are 
supported in Smalltalk/V, Team/V adds Class Instance Vari¬ 
ables, Comments (for both the class and variables), and class 
initialization. Message categories are also implemented for 
classifying, or grouping methods. Although the notion of 
public and private methods is not directly implemented, as in 
ENVY, private methods can be placed in a category named or 
containing “Private,” which would provide the benefits of 
documenting the public/private protocol of the class. 

Conflict Resolution 

When a package is loaded Team/V first checks for any 
conflicts. A conflict occurs when one of the definitions of a 
package you are trying to load has the same name as one of the 
definitions already loaded in your image. A conflict also occurs 
if you attempt to load a class extension for a class that is not 
defined. Conflict resolution only occurs when you load a pack¬ 
age. Using the Install/File-In menu items does not perform 
conflict resolution. However, with the Package/Load operation 
one can select any source file and have the conflict resolution 
performed when filing in source in nonpackage format. 
Team/V then generates a package named “From: <filename>," 
which you can then rename to an appropriate name. 

NEW BROWSERS 
Package Browser 

The Package Browser is a new tool for working with Packages 
(See Fig. 1). The package browser has four panes at the top. 
The top left pane shows the packages in the image. Packages 
that are only opened and not loaded are enclosed in parenthe¬ 
ses. Open packages are packages that are only open for inspec¬ 
tion; they are not part of the executable image. Open packages 
are useful for comparing with other revisions of the same 
package or any other package. You can also modify and com¬ 
mit a new version of an open package. In this way you can re¬ 
solve a conflict in a package you are attempting to load. 

The second pane from the left shows global definitions 
(classes, global variables, and pool dictionaries) for the selected 
package. The third pane from the left shows the message cate¬ 
gories for the selected definition if the definition is a class. And 
finally the right pane shows the methods for the selected cate¬ 
gory, if a category has been selected. A nice feature of the 
method list is that it can show inherited methods in addition 
to those defined within the selected class. 

The lower half of the package browser shows various as¬ 


pects of a definition, a class definition (as shown in the 
figure), method source if a method is selected, or any of the 
comment fields that the system supports. This pane is the pri¬ 
mary place for modifications to be made. In fact, the Class Hi¬ 
erarchy Browser has been made read-only in Team/V. Source 
code formatting for method source is also available from the 
package browser. 

Some of the panes support direct manipulation (drag/drop) 
for moving components around. However, because the panes 
are not multiselect, I found this to be tedious at times. For ex¬ 
ample, a definition that defined a class could be moved from 
the definitions list to a different package, but a definition that 
was only a class extension could not. In this case, each method 
had to be moved individually. This tedium occurs mainly 
when you are filing in external source while constructing your 
packages for the first time. ENVY defines a default application 
that receives all filed-in code. I found the default application 
mechanism to be more convenient. 

The browsers show modified components in italics and a 
different color, defined classes are in bold while class exten¬ 
sions are not. These visual cues are excellent for grasping what 
changes have been made since the last commit. 

Definition Organizer 

The Definition Organizer lets you examine the definitions 
within a package in the order in which they will be initialized. 
You can reorder the definitions as necessary. The top left pane 
shows the packages currently loaded or opened, the top right 
pane shows the definition list for the selected package, the 
lower left pane shows the annotations for the selected package 
or definition and the lower right pane shows the source for the 
selected definition or annotation (See Fig. 2). 

While the Package browser only allows specification of 
global definitions only (class, pool and global variable defini¬ 
tions), the Definition Organizer allows all types of definitions to 
be specified. Only the definition organizer allows for the ad hoc 
initializers to be added. The Definitions Organizer is also the 
tool to use for annotating a Package. 

Definition Group Browser 

The Definition Group Browser has the same appearance as the 
familiar method browser so I have not shown it. The main 
difference is that the contents can be any definition (e.g., 
method, class, initializer, etc.) rather than just methods. A nice 
feature added to the Smalltalk menu is Browse — 

>Modified. . .which brings up a Definition Group Browser on all 
definitions that have been modified since you last committed 
the packages. 

History Browser 

The bottom right of the Team/V browsers contain a button 
labeled with version information for the given definition. 
Clicking on this button brings up a History Browser that con¬ 
tains all the known versions of the definition. The versions 
known are only those since the last compress of the changes 
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The Pack&Qe Comparison Browser. 


file. This differs from ENVY where every save of a method 
saves an edition in the repository that can later be browsed 
and compared with other editions. I expected to have ver¬ 
sions of methods in opened packages available in the History 
Browser, but they were not. Not being able to have history di¬ 
rectly available for versions of methods across versions of 
packages is a definite disadvantage. 


Documentation 

Team/V’s documentation is very good and 
easy to use. In addition to the explanation of 
how the new browsers work, there is a chapter 
that explains the concepts behind Team/V 
and a tutorial that acquaints the new user 
with the development process under it. One 
very useful chapter answers questions that 
arise during the development process. Ques¬ 
tions like, “How do we divide up the work of 
the application?” (i.e., along what lines should 
we define our Packages?). 

The Team/V Programmatic Interface 

The Programmatic Interface is a mapping of 
the semantic components of Team/V into 
classes that you can use to create your own 
custom tools and browsers. Digitalk’s inten¬ 
tion is to keep this interface compatible in 
future releases of Team/V. Multiplatform 
development could be built using this inter¬ 
face and an annotation convention on packages. Using an 
annotation named something like “Platform” and having 
values that indicate the intended platform for the package 
(e.g., “All,” “PM,” “Win,” etc.) one could extend the system 
with a “smart” export to have something like ENVY applica¬ 
tion line-ups, thereby providing some amount of multiplat¬ 
form support. 


COMPARISON TOOLS 

Team/V allows you to compare two versions of a method, or 
two revisions of a package. 

Method Comparison Browser 

Selecting Method—> Compare from a Package Browser or Ver¬ 
sion—> Compare from a History browser brings up a Method 
Comparison Browser. The Method Comparison browser is basi¬ 
cally two method browsers side by side. The differences be¬ 
tween the two selected versions of the method are shown both 
in a different color and underlined. 

Package Comparison Browser 

Team/V allows you to compare two versions of a given pack¬ 
age, or you can compare two completely different packages 
(See Fig. 3). The top two panes are the revisions list; revisions 
of all packages appear. The middle two panes are the defini¬ 
tions list. Definitions that are in one revision but not the 
other are in boldfaced text. Definitions that are in both are in 
italics. The bottom panes are the contents panes with differ¬ 
ences underlined. 

The granularity of versions is finer in ENVY than Team/V. 
ENVY maintains versions of methods, classes, subapplications, 
applications, and Configuration maps (groupings of applica¬ 
tions) in the repository while Team/V maintains only versions 
of packages. 


OTHER DIFFERENCES 

ENVY defines configuration maps that are groupings of appli¬ 
cations that other developers can load to bring their image up 
to a given point in the development process. Configuration 
maps are stored in the repository as are all components in 
ENVY. Team/V does have a Build Script operation that will 
build a script that a developer can run to load current packages 
into her image. But because they are not stored in the reposi¬ 
tory, the management would not be as easy. 

A particularly hot issue of late on the CIS Digitalk forum 
has been image size. ENVY includes a packager that will create 
a separate runtime image containing only the code that is re¬ 
quired at runtime. One drawback of this is that changes that 
Digitalk makes to its implementation of Smalltalk affect the 
packager. There was a long delay between the release of 
Smalltalk/V OS/2 2.0 and a packager that worked for it. One 
reason you may want to stay with a single source for tools. 

Team/V is not supported on ParcPIace’s Smalltalk. Many 
large companies have projects using both the Digitalk and Par- 
cPlace versions of Smalltalk. With ENVY these projects could 
share a common repository. 

CONCLUSION 

Both Team/V and ENVY share all the mechanisms to support 
team development and version control. If you are delivering a 
standalone commercial application on multiple platforms, 
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ENVY with its packager for producing minimal sized delivery 
sets and application line-ups for supporting multiplatform de¬ 
velopment seems better positioned. If on the other hand you 
are in an enterprise that has standardized on a platform and 
you are delivering many Smalltalk applications that can share 
base class libraries, you can easily package your applications in 
object libraries and have small images that bind to needed li¬ 
braries and open the required user interface. In this case, 
Team/V provides all the needed tools. Hi 
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■ Smalltalk idioms 

continued from page 16 
display 

I *y I 

x :=y := o. 

10 timesRepeat: 

[picture displayAtX: x y: y. 
x := x + 2. 
y :=y+ 2 ] 

Using objects from methods, we notice that x and y are used 
together. We create a point object with x and y variables. We 
can then simplify the above method to the following: 

display 
I P I 

p := Point x: 0 y: 0. 

10 timesRepeat: 

[picture displayAt: p. 

p:=p + 2 ] 

I don’t find this example compelling, but if you had an algo¬ 
rithm that used a half dozen points, you could easily get lost in 
the thisX, thisY, thatX, thatYs. The transformation would make 
much more difference. 

Ward Cunningham told me a story of using this pattern on 
a piece of financial software. There was one method that was 
long and ugly, but it was important because it computed the 
value of a bond at a given moment. As soon as they turned the 
method into its own object, the computation came into focus. 
These advancer objects became the centerpiece of their 
caching strategy. 

In my next column, I will end my series on the origin of ob¬ 
jects by examining two common patterns for finding objects: 
objects from the user’s world and objects from the interface. El 
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FINALLY 

CLIENT/SERVER 

INTEGRATION. 
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Not long ago, client/server 
development required massive 
amounts of time, money and 
expertise to combine different 
and complex technologies. 

Now Digitalk 

PARTS__ m. PARTS? a rapid 
application 
development 
tool set, lets you 
easily integrate 
your software 
assets into 
client/server applications. 

PARTS is the only object- 
oriented technology that lets 
you leverage your legacy code 
and the knowledge of your 
current staff. 

Only PARTS products let 
you take existing code-written 
in Smalltalk/V, COBOL, C, SQL 
and other languages-and wrap 
it into components or "parts" 

Which can then be virtually 
snapped together visually. The result 
is smooth-running client/server 
applications in a fraction of the 
usual time. For a fraction of the 
usual cost. 

PARTS supports all popular 
SQL databases like Sybase, Oracle 
and DB2. Plus legacy or late model 



systems like CICS, COBOL, APPC 
and SOM. And PARTS lets you 
develop on both OS/2 and Windows. 


RATED #1-TWICE. 


Only months ago, PC WEEK 
awarded PARTS Workbench the 
highest rating ever in the OS/2 


category, calling it "the defini¬ 
tive visual development tool" 

And InfoWorld ranked 
PARTS the #1 component- 
based tool for visual develop¬ 
ment. InfoWorld’s Stewart 
Alsop adds: “There's nothing 
like it on the PC." 

To make large teams pro¬ 
ductive, PARTS also supports 
group development and version 
control. Plus PARTS has a host 
of graphical power tools to give 
you all the power of objects - 
without the learning curve. 


= ■ 10 YEARS EXPERIENCE. 


And PARTS is from 
Digitalk. The company that’s 
been providing object-oriented 
tools to the Fortune 500 longer 
than anyone else in the world- 
with over 125,000 users. 

Call 800-531-2344 X 610 
—■ and ask about our 
PARTS Workbench 
Evaluation Kit. 

With minimum 
effort, you'll learn why 
PARTS is the maximum 
solution for client/server 
integration. 


PARTS 


DIGITALK 



















































































































































































